git and Github

A practical introduction

Daniel Thédié

18/02/2026

Check-in

House rules

What makes you want to use Github?

What makes you not want to use Github?

Basics of git and github

What is a git repository?

  • A (local) folder
  • A .git folder that contains all the file history

How are changes recorded

  • A commit records a snapshot of the project
  • It is identified by a unique “hash”, e.g. 87c0c975daf0643d59a01222b312662d347e0bfa
  • Shown on github as the first 7 characters for readability: 87c0c97

Is git overly complicated?

Can we not make a google docs for code?

  • Real-time updates
  • Collaboration
  • Complete file history

What git adds…


The process makes the user decide…

  • What they share (which files)
  • When they share (working on files locally and pushing them when ready)
  • Why they share (for other people to use the code, to collaborate on code…)

How to collaborate with git(hub)

Pull - Modify - Stage - Commit - Push

From theory to practice

  • Go to github.com
  • Click on “New”
  • Enter a name and description
  • Make repository public or private
  • Tick “Add a README file”

  • Click on “< > Code”
  • Copy the https link to the repository

  • In RStudio, create a new project
  • Select:
    • Version control
    • Git
  • Enter repository details
  • Identify to Github
  • Add some code files to the repository
  • They will be shown in the RStudio git tab

  • Stage the newly added files

  • Commit (with a message)

  • Push

    • Committed files are now on Github
  • Open the .gitignore file
  • Add *.Rproj on a new line
    • The .Rproj file has disappeared from the git tab
  • Commit .gitignore

The Readme file

A practical overview of the repository, in markdown format

  • What can be found in here?
  • What’s the purpose of the code (+ inputs/outputs)
  • How to use the code
  • Who are the authors (with contact info)

Readme example

github.com/BioRDM/Network-Analysis

Why use branches

Why use branches

Why use branches

Why use branches

Creating a branch

  • Create a new branch “dev” in your repository

  • Make some changes to a file

  • Stage, commit, push

  • Switch between branches

    • Each branch has a different file version

Short break

Good coding practices

Code modularity

library(readxl)
library(ggplot2)

sessions_file <- "example_sessions.csv"
min_sleep_period <- 2  # hours

file_ext <- tolower(file_ext(sessions_file))
if (file_ext == "csv") {
  sessions <- read.csv(sessions_file)
} else if (file_ext %in% c("xls", "xlsx")) {
  sessions <- read_excel(sessions_file) |>
    as.data.frame()
}

sessions <- sessions[sessions['sleep_period'] >= min_sleep_period * 60 * 60, ]

p <- ggplot(sessions, aes(x = .data$night, y = .data$variable, color = .data$color_group)) +
  geom_point(size = 5) +
  color_scale +
  labs(x = NULL, y = variable, color = NULL) +
  theme_minimal(base_size = 16) +
  theme(axis.text.x = element_text(angle = 45, hjust = 1))

print(p)

Code modularity

sessions_file <- "example_sessions.csv"
min_sleep_period <- 2  # hours

sessions <- load_sessions(sessions_file)

sessions <- set_min_sleep(sessions, min_sleep_period)

print_timeseries_plot(sessions)


  • Makes code more human-readable
    • Creates different “levels of reading”
  • Facilitates reuse in different scripts
  • Facilitates collaborative work

1. Create functions

  • A “processing unit” with clear inputs and outputs
  • Can be described simply with a verb + a noun
    • “load_data”, “set_ema_period”
  • In general shorter is better
set_min_sleep <- function(sessions, min_sleep) {
  sessions <- sessions[sessions['sleep_period'] >= min_sleep * 60 * 60, ]
  return(sessions)
}

2. Split code between different files


source("R/filtering.R")
  • One file per “topic”
  • If a file gets very long, consider splitting it
  • Easily see what part of the code a commit has affected

Make your code more modular

  • Checkout dev branch
  • Create functions
  • Organise them in different files

Function template:

set_min_sleep <- function(sessions, min_sleep) {
  sessions <- sessions[sessions['sleep_period'] >= min_sleep * 60 * 60, ]
  return(sessions)
}

…commit and push your changes to github

Short break

GitHub functionalities

Time to make your first pull request (to yourself)

On github, create a pull request to merge dev into main.

When merges are more complicated

Issues

  • Like a centralised to-do list
  • Keep track of things to do together
    • When there are multiple users, it’s also useful for them to know which bugs have already been reported
  • Each issue gets its own discussion feed
  • How to close an issue via commit (fixes #1)
  • Don’t be scared of issues! Code is never perfect
    • Foster a culture of openness

Github is not the only way

  • Github doesn’t own git!
  • Any other website can provide similar functionalities
  • Examples: Gitlab, codeberg, forgejo…
  • …including the Uni’s own gitlab instance! (IT resilience)